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Abstract NASA is planning a series of short and long 
duration human and robotic missions to explore the Moon 
and then Mars. A key objective of the missions is to grow, 
through a series of launches, a system of systems 
communication, navigation, and timing infrastructure at 
minimum cost while providing a network-centric 
infrastructure that maximizes the exploration capabilities 
and science return. There is a strong need to use 
architecting processes in the mission pre-formulation stage 
to describe the systems, interfaces, and interoperability 
needed to implement multiple space communication 
systems that are deployed over time, yet support 
interoperability with each deployment phase and with 20 
years of legacy systems. In this paper we present a process 
for defining the architecture of the communications, 
navigation, and networks needed to support future space 
explorers with the best adaptable and evolable network- 
centric space exploration infrastructure. The process steps 
presented are: 1 ) Architecture decomposition, 2) Defining 
mission systems and their interfaces, 3) Developing the 
communication, navigation, networking architecture, and 
4) Integrating systems, operational and technical views 
and viewpoints. We demonstrate the process through the 
architecture development of the communication network 
for upcoming NASA space exploration missions. 

Keywords: system architecting, architecting process, 
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1 Introduction 

1.1 Background to NASA Methodologies 

NASA has a long history of aggressively using the 
system engineering processes described in the NASA 
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System Engineering Process Handbook SP-610S on 
mission developments. As space exploration is, by its 
nature, a complex system of systems (SoS), effective use of 
SoS engineering processes and methodologies is being 
pursued by the NASA Space Communication and 
Navigation (SCaN) program throughout each phase of 
exploration architecture development. This process 
addresses large-scale inter-disciplinary problems with 
multiple, heterogenous, distributed systems that involve 
networks at multiple levels and multiple domains. 

NASA’s near term exploration plans [1] call for 
human and robotic missions to the Moon [2, 3] and require 
development of architecture in the mission formulation 
stage. Existing resources and legacy systems, such as 
International Space Station (ISS) and the existing space- 
based and ground-based network assets, will be integrated 
with new systems developed and deployed at different 
exploration phases; yet they will work as an integrated 
system of systems for supporting future space exploration 
missions. Communication systems which must interoperate 
include the crew exploration vehicle (CEV), Earth relay 
satellites, lunar relay satellites [4], lunar surface 
communication infrastructures [5], Mars relay satellites, 
etc. Yet all of the existing and future assets have to 
interoperate to realize the high capacity, high performance 
SoS attributes needed to provide superior communication, 
navigation, timing, and information services. These 
capabilities, driven by emerging exploration requirements, 
[6, 7] will enable future astronauts to conduct space 
exploration, communicate with Earth-based scientists and 
excite future generations of explorers with high definition 
video and in-presence exploration, and return safely to 
earth at the end of the mission. 


The process for 

describing the needed com- 
munications, navigation, and 
networking entities as a SoS 
construct is being accomp- 
lished by using standard 
system engineering methods 
for defining and gathering 
capability requirements, and 
identifying a generalized 

initial architecture. 

Additional steps include 

decomposing the architecture 

and using the Department of 
Defense Architecture Framework (DoDAF) operational, 
system, and technical view diagrams, and then refining the 
architecture as actual functional requirements are identified 
during the architecture development process. 

2 Architecture Decomposition 
Process 

The SCaN Network will interface with all exploration 
missions from pre-launch testing through crew recovery at 
the end of each mission. SCaN and its resources will 
support each mission at launch, in low earth orbit (LEO), in 
early docking with ISS, in transit to and orbit around the 
Moon or Mars, during lunar or Mars landing, on the lunar 
or Mars surface, and during the trip back to Earth. SCaN 
will be compatible with space exploration customers to 
provide seamless communication, tracking, and timing 
services. 

The SCaN system development, including CEV-ISS 
mission phase (phase 1) and follow-on lunar phases, will 
take place over multiple phases, each spanning multiple 
years during which the political, management, and 
contractual arrangement can change. Further complexity is 
added by the sheer fact that the post phase 1 system has to 
provide communication and tracking services to space and 
planetary surface assets based on multi-layered 
architectural information systems. 

During the CEV-ISS mission phase, which this paper 
addresses, SCaN will provide the communications and 
tracking services to support CEV-ISS missions. However, 
the SCaN architecture will be designed in a manner that 
will fully support later lunar and planetary mission 
upgrades as well. 

The architecture views will convey the SCaN architecture 
to all the stakeholders (customers, system engineers, 
implementers, etc.) to assist them in verifying that the SoS 
will address their concerns. The depiction of the CEV-ISS 
mission phase SCaN architecture in this paper has been 
developed using the Department of Defense Architecture 
Framework (DoDAF) views as a starting point. The SCaN 
Network requires the integration of architectural practices 


across multiple disciplines. 
Such practices are based on 
the views of disparate 
stakeholders in the 

architecture; model-based 
analyses of elements of the 
architecture by subject- 
matter experts; and 

collaboration among the 
stakeholders, the architect, 
and the experts during the 
evolution of the architecture 
(as captured by view 
development) to final 

consensus. 

A hierarchical document structure is used to present the 
complex CEV-ISS mission phase SCaN Network 
architecture in an efficient manner to a variety of users with 
differing needs. Thus, the amount of detail presented 
increases with each successive level as shown in Figure 1. 
The SCaN Network architecture is described in terms of its 
operational, system, and technical attributes so that the user 
can gain insight into how it fulfills its mission objectives. 
The SCaN Network architecture is decomposed into 
segments and elements. In order to relate the parts of the 
CEV-ISS mission phase SCaN Network architecture to its 
whole, the descriptions for each level are intended to show 
how segments and elements support the operational, 
system, and technical aspects of the architecture. 

3 Defining NASA Mission Systems 
and Their Interfaces 

A number of NASA exploration architecture teams and 
study groups have defined the systems to be deployed 
during the exploration missions. CEV is one of the critical 
systems which will carry the astronauts to Earth orbit and 
beyond. Several additional systems come into play to carry 
CEV into space and then to the Moon. A lunar outpost to 
be developed on the surface of the Moon will require 
another set of systems to support the lunar exploration 
missions which follow. In Figure 2, the notional 
communication and navigation systems shown provide the 
interfaces among the explorations systems on the Earth 
surface, in Earth orbit, in trans-lunar space, in lunar orbit 
and on the lunar surface. Many of the systems are dynamic 
in nature, which adds to the complexity to be addressed 
during the development of the architecture. 

4 End-to-End Communication 
Architecting Process 

The SCaN Network architecture will pursue an aggressive 
adoption of common communications links and protocols, 
drawing from standards-based IP network technology and 
effective use of layering to isolate functions and to 
aggregate common functions to maximize interoperability. 



Figure 1. Architecture Decomposition 
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Figure 2. Notional System Communication Navigational Functions and Interfaces 


NASA’s space communication system must be flexible and 
evolvable enough to adapt to changing technology, 
changing missions, and user needs that will inevitably 
occur over the next 20 years. With the short Earth-based 
Internet generational life cycles and communication-rich 
appli-cation training of future astronauts, the space-based 
command, control, communication, and information (C3I) 
capabilities will need to be raised to meet the expectations 
of future users. 

4.1 Communications Architecture 

The SCaN Network architecture for CEV-ISS missions will 
include the NASA Ground Network (GN), Space Network 
(SN), NASA Integrated Services Network (NISN), Flight 
Dynamics Facility (FDF), and new SCaN Network Control 
Center (NCC), which are depicted in Figure 2. The SCaN 
Network communication architecture will provide end-to- 
end S-band services to the CEV, end-to-end Ka-band 
services to the CEV, and end-to-end S band services to the 
CLV during all CEV-ISS mission phases. The SCaN 
network end-to-end S-band and Ka-band services will 
support communications, radiometric tracking, and timing 


synchronization activities. For CEV-ISS missions, the end- 
to-end services will be based upon the Internet Protocol 
(IP) as requested by the exploration missions; therefore, the 
SCaN Network will support the end-to-end transfer of IP 
packets between the CEV/CLV and ground-based mission 
elements like the MCC, as depicted in Figure 3. 

4.2 IP Compliant Networking Architecture 

The SCaN Network consists of numerous new and 
legacy system elements included in the Ground Network 
(GN), Space Network (SN), Deep Space Network (DSN), 
NASA Integrated Services Network (NISN), and network 
elements that will be added as space exploration extends to 
the Moon and Mars. Some system elements, such as the 
Deep Space Network (DSN) and Johnson Space Center 
(JSC), have over 20 years of legacy hardware, software, 
and policies. These networks are administered by different 
control center software systems and operational policies. 
To put together an IP compliant end-to-end management 
system with human rated real-time responsiveness requires 
stitching numerous different administrative systems and 
domains with different policies, priorities, and management 
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Figure 3. Layered IP Network Links Ground and Space Together 


systems into an integrated system that can plan, allocate, 
control, deploy, coordinate and monitor the resources of the 
network to support space exploration. Many of the legacy 
systems supporting existing space missions also have to 
evolve into the future architecture to meet the space 
exploration mission requirements. Currently, GN, SN and 
DSN do not provide a network interface to missions; we 
need to extend network layer capabilities to space. Quality 
of Service (QoS) over different domains poses another 
challenge in mapping and preservation of QoS integrity 
over multiple domains. With human lives at stake on Mars 
or the Moon, automation, automatic error recovery, and 
local distributed control will have to be pervasive in the 
architecture. 

4.3 Propagating Navigation Architecture to Space 

As the SCaN Network is deployed in space from Earth- 
based to lunar and Mars network support, a system of 
coarse and fine-grain navigation references will be 
integrated with the SCaN Network to enable future space 
explorers and applications to access navigation and position 
services. 

5 Applying DoDAF Views 

The use of DoDAF methodologies is not mandated for 
NASA systems, but selected key DoDAF views are being 
used to identify architecture issues and gaps. This is being 
done by utilizing the generation of crosscutting views of 
the multitude of NASA as-is legacy systems and IP 
network compliant decomposition views of the future 
network layers and network-centric architecture. The 
architecture diagramming methods used range from the 


defined DoDAF graphical views to custom diagrams that 
use pictorial icons to represent nodal entities. 

Three views are defined within DoDAF for an architectural 
description, namely, operational views (OVs), system 
views (SVs) and technical standard views (TVs). We have 
adopted a subset of the OV and SV products to describe the 
CEV-ISS Mission phase that NASA is initiating as a 
precursor to future lunar and Mars exploration. 
Communication and navigation systems and operational 
activities evolve over different mission stages. For 
example, testing communications to crew and launch 
vehicles prior to launch, versus supporting communications 
and tracking of the crew vehicle in low-Earth orbit, involve 
different systems and operations. The graphical products 
used to capture evolving communication and navigation 
scenarios provide an architectural description for each stage 
of the mission. For the CEV/ISS mission phase, four main 
mission stages were used, namely, (i) pre-launch testing; 
(ii) launch and ascent; (iii) FEO-orbit including rendezvous 
and docking with the International Space Station (ISS) and 
(iv) de-orbit, re-entry, descent, landing and recovery. A 
few examples of the architectural description products are 
presented next. Figure 4 shows an OV-2 diagram that 
describes the operational node connectivity for the mission. 
The colored boxes indicate the operational nodes. The 
connections between the nodes are considered needlines; 
the bubbles along the needlines display the information that 
must be passed from one node to another to enable each 
node to accomplish its operational tasks. 

Figure 5 shows an example of a system interface 
diagram (SV-1) representing the first 350-seconds of 
launch. Critical Events include first-stage separation and 
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Figure 4. DoDAF OV-2 Operational Node Connectivity Description 


establishing primary communications with the TDRS 
satellites. During the first 350 seconds, the CLV may be 
downlinking live imagery to the launch-head. Interfaces 


between US Air Force range safety and CLV in the event 
of required flight termination are also shown. 
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Figure 5. SV-1 for Launch and Ascent Phase of the CEV-ISS Mission , TO to »T+6.5 minutes 











6 Conclusions and Future Work 

We have described a system engineering and system 
architecture process for decomposing the NASA Space 
Exploration system-of-system vision into the incremental 
upgrade components that will enable NASA’s future 
communication, navigation, and timing architectures. As 
the program marches forward, future innovations in the use 
of architecture processes and tools are anticipated to create 
a world-class infrastructure to advance man’s exploration 
in space. 

The next step is to pursue an aggressive plan to develop 
and use a rich suite of integrated modeling and simulation 
processes and tools, a suite of system engineering and 
integration tools, and a distributed testbed network of 
multiple system integration laboratories. 

With effective integration of the development environment 
and tool fidelities, the modeling and simulation tools can be 
useful in all phases of implementation including 
architecture definition, requirement decomposition, design, 
test definition, test validation, training, and the resulting 
operations. 

During the architecture and requirements definition phases 
of the program, modeling and simulation are used to study 
architecture trade-offs for making key architectural 
decisions based on identified driving requirements, 
validation of requirements feasibility, comparison of trade 
alternatives, performance optimization, and risk reduction 
by simulating the operational scenarios. System 
engineering tools to manage requirements and architecture 
definition are key in automation of system engineering 
functions such as requirement flowdown, test planning, risk 
management, functional and operational flow 
decompositions. 

During the test phase, modeling and simulation tools 
integrated with an emulation testbed environment can cost- 
effectively reduce program risk by verifying and validating 
operational test scenarios, identifying early integration and 
validation risk areas, performing metric collection, and 
refining details for concept of operations (CONOPS) and 
operational procedures. 

The authors wish to acknowledge the support of Ms. 
Paulette Ziegfeld in preparing this paper. 
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